home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc644 < prev    next >
Text File  |  1995-07-25  |  10KB  |  228 lines
  1. Network Working Group                                   Bob Thomas
  2. Request for Comments: 644                               BBN-TENEX
  3.                                                         Jul 1974
  4.  
  5.      On the Problem of Signature Authentication for Network Mail
  6.  
  7. This note describes the problem of signature authentication for network
  8. mail, presents a general approach to the problem and proposes a specific 
  9. implementation of that approach.
  10.  
  11.  
  12. 1. The Problem
  13.  
  14.    The problem we wish to consider is:
  15.  
  16.       How can the recipient of a network mail message be "certain"
  17.       that the signature (e.g., the name in the "FROM" field) is
  18.       authentic; that is, that the message is really from whom it
  19.       claims to be?
  20.  
  21. We are interested in the problem of signature authenticity in the network
  22. context.  For purposes of this note we shall assume a solution to the
  23. signature authentication problem for local mail (i.e., messages from one
  24. user to another within a single host).  That is, we assume that for any
  25. host, either the host regards the problem as important and has a mechanism
  26. for guaranteeing signatures on local mail or that the host does not regard the
  27. problem as important and does not guarantee signature authentication.  It
  28. should become clear how this assumption relates to our approach to the network
  29. signature problem.
  30.  
  31. We shall discuss our approach using the following simple model for network
  32. mail:
  33.  
  34.       To send net mail a user invokes a mail sending process (SP) on
  35.       his local host (SH).  The process SP acts on behalf of the user
  36.       to deliver the message to an appropriate mailbox at the
  37.       receiving host (RH).  It does that by interacting with a
  38.       receiving process (RP) that runs on host RH.  RP accepts the
  39.       message from SP and deposits it in the appropriate mailbox.
  40.  
  41. In the current implementation of network mail, the receiving process RP is 
  42. typically an FTP server process.  For the current TENEX implementation the 
  43. mail sending process SP is either a process running SNDMSG or a "background" 
  44. MAILER process which sends "queued" (previously posted but undelivered) mail.
  45.  
  46.  
  47. 2.  An Approach
  48.  
  49. We seek a solution which will allow RP, the receiving process, to mark
  50. the signature on messages it receives as authenticated or not with
  51. respect to SH, the sending host.  If RP can so mark incoming messages,
  52. a user reading his mail at RH would be able to see the signature on each
  53. message as authenticated or not with respect to the host of origin.  The
  54. authenticity of the signature on a piece of mail is understood to be 
  55. responsibility of the originating host.  The credibility a user gives a
  56. particular message which is marked as authentic can be based on the user's
  57. own estimate of the source host's user authentication and access control
  58. mechanisms.
  59.                                      -1-
  60.  
  61.  
  62.  
  63.     The success of this approach depends upon two things:
  64.  
  65.     a.  Users develop estimates of the security of various host user
  66.         authentication and access control mechanisms.  We have seen that
  67.         users who are concerned about data privacy and security are
  68.         already doing this within the ARPANET.
  69.  
  70.     b.  The existence of a mechanism which RP, the receiving process,
  71.         can use to distinguish mail authenticated with respect to the
  72.         sending host from mail that has not been authenticated by the
  73.         sending host.  That is, a mechanism is required which will allow a
  74.         properly authorized (by the sending host) mail sending process to
  75.         identify itself as such to the mail receiving process.  The
  76.         receiving process can then mark mail from such an authenticated
  77.         process as authentic.  Nonauthorized processes (e.g., a user
  78.         process attempting to pose as an authorized mail sending process)
  79.         may try to send mail to mailboxes at RH; in such a case the
  80.         receiving process has the option of refusing to accept the message
  81.         or accepting them marking them as unauthenticated.
  82.  
  83.  
  84. 3.  Proposed Implementation of Approach
  85.  
  86. The use of passwords is one possible way to accomplish sending process
  87. authentication.  Only an authorized sending process would know the password
  88. and thus be able to properly identify itself to a mail receiving process.
  89. We reject the password mechanism as operationally impractical for the following
  90. reasons:
  91.  
  92.     a.  Use of a password requires that the password be stored in
  93.         the sending program or be accessible to it in some way thereby
  94.         increasing the likelihood that the privacy of such a password will
  95.         be compromised.
  96.  
  97.     b.  If a password is compromised, it must be changed at both
  98.         sending and receiving hosts; a synchronization problem.
  99.  
  100.     c.  Truly secure mail would probably require passwords for each
  101.         pair of hosts; this requires N*N passwords for an N host network.
  102.  
  103. As an alternative to the use of passwords as a means for process
  104. authentication, we propose that authentication be based on the
  105. communication path itself between the sending and receiving process.
  106. In the ARPANET, a communication path is uniquely identified by its two
  107. ends: the send host-socket pair and the receive host-socket pair.  A
  108. process can accurately determine the host-socket pair at the remote end
  109. of a communication path.  We propose that the receiving process
  110. consider the sending process to be a properly authorized (by the
  111. sending host) sender of mail only if the sending end of the
  112. communication path is (one of) the socket(s) reserved for transmission
  113. of authenticated mail.  The mail sending socket(s) would be reserved
  114. by prior host agreement.
  115.                                    -2-
  116.  
  117.  
  118.  
  119. The responsibility of the sending host is to allow only authorized
  120. mail sending processes to access the mail sending socket(s).  The
  121. responsibility of the user concerned about the authenticity of his
  122. mail is to understand that mail marked as authentic means that the
  123. sending host has determined the identity of the sender and that the
  124. signature on such mail is only as good or bad as the user authentication
  125. and access control procedures of the sending host.
  126.  
  127.  
  128. 4.  Additional Remarks
  129.  
  130.     a.  The use of sockets for process authentication is not a new concept
  131.         within the ARPANET.  By host agreement, the TELNET logger process
  132.         responds to connections to socket #1, the FTP logger process to socket
  133.         #3, etc.  In fact, the privacy of net mail depends upon how well the
  134.         host controls access to the FTP logger socket; that is, the
  135.         authenticity of the mail receiving process is based upon that fact
  136.         that it is the process reached by ICP'ing to socket #3.  This note
  137.         proposes that the same mechanism be used to provide authentication of
  138.         mail sending processes.
  139.  
  140.     b.  Planned TENEX Experiment
  141.  
  142.         A set of sockets has been assigned for mail transmission.  They are
  143.        (all numbers are decimal)
  144.  
  145.            ICP "from" socket - 232
  146.            FTP user command sockets:  receive, send = 234, 235
  147.            Default data transfer (user, send) socket = 237
  148.  
  149.         We intend to modify the TENEX mail sending, receiving and reading
  150.         software as suggested above.  Mail sent by TENEX to remote hosts
  151.         which is authentic (with respect to TENEX) will be sent by initiating
  152.         the ICP to the remote FTP server socket 232.  Mail received from
  153.         remote hosts will be marked as authentic only if the ICP to the TENEX
  154.         FTP server was initiated from remote socket 232.  The TENEX mail
  155.         reading software will indicate for each message whether or not the
  156.         signature on the message was source authenticated.
  157.  
  158.     c.  Contention for the Mail Sending Socket
  159.  
  160.         Depending upon the implementation of the sending host's NCP and
  161.         its mail net sending software, it may be the case that several users
  162.         concurrently sending network mail may be competing for the single
  163.         ICP "from" socket.  If socket contention turns out to be a serious
  164.         problem in practice, a set of ICP "from" sockets could be reserved
  165.         for authenticated network mail.
  166.  
  167.     d.  The local mail signature authentication problem is nearly independent
  168.         of the network mail signature authentication problem as we have
  169.         discussed it.  For example, the following observations can be made:
  170.                                      
  171.                                      -3-
  172.         1.  The local users of a host which does not authenticate local mail
  173.             probably should not expect the host to reliably deliver
  174.             authenticated network  mail to them.  Because local mail is not
  175.             authenticated, it is likely that a malicious local user could
  176.             add to other users' mail boxes forged messages which are formatted
  177.             identically to net mail and are marked as authentic in the way
  178.             the host's mail receiving process marks mail.
  179.  
  180.         2. A host that has strong user authentication procedures and
  181.            authenticates local mail is not necessarily a reliable source
  182.            of authenticated network mail.  In order to be a reliable source,
  183.            it must limit access to the net mail transmission socket(s) to
  184.            authorized mail sending processes.
  185.  
  186.        3.  A host which does not support local authentic mail could be a
  187.            reliable source of authentic net mail.
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.   
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.                                    -4-